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(54) Method and apparatus for enforcing the use of cryptography in an International 
cryptography framework 



(57) A cryptographic framework consists of four 
basic service elements that include a national flag card, 
a cryptographic unit, a host system, and a network 
security server. Three of the four service elements have 
a fundamentally hierarchical relationship. The National 
Flag Card (NFC) is installed into the Cryptographic Unit 
(CU) which, in turn, is installed into a Host System (HS). 
Cryptographic functions on the Host System cannot be 
executed without a Cryptographic Unit, which itself 
requires the presence of a valid National Flag Card 
before it's services are available. The fourth service ele- 
ment, a Network Security Server (NSS), can provide a 



range of different security services including verification 
of the other three service elements. Several different 
configurations that support policy within a cryptographic 
system allow the framework to be adapted to various 
connection schemes involving, at least, the crypto- 
graphic unit and the policy, including dedicated applica- 
tions, e.g. a policy provided in a cryptographic unit 
having either a built-in or local smart card reader, or a 
policy in a remote smart card reader; and shared appli- 
cations, e.g. a policy provided in a host system local 
smart card reader. 
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Description 

BACKGROUND OF THE INVENTION 

TECHNICAL FIELD 

The invention relates to cryptography. More particu- 
larly, the invention relates to enforcing a policy that gov- 
erns the use of cryptography within the context of an 
international cryptography framework. 

DESCRIPTION OF THE PRIOR ART 

Customers of large computer systems are typically 
multinational corporations that want to purchase enter- 
prise wide computer based solutions. The distributed 
nature of such organizations requires them to use public 
international communications services to transport data 
throughout their organization. Naturally, they are con- 
cerned about the security of their communications and 
seek to use modern end-to-end cryptographic facilities 
to assure privacy and data integrity. 

The use of cryptography in communications is gov- 
erned by national policy and unfortunately, national pol- 
icies differ with respect to such use. Each national 
policy is developed independently, generally with a 
more national emphasis rather than international con- 
siderations. There are standards groups that are seek- 
ing to develop a common cryptographic algorithm 
suitable for international cryptography. However, the 
issue of international cryptographic standards is not a 
technical problem, but rather it is a political issue that 
has national sovereignty at its heart. As such, it is not 
realistic to expect the different national cryptography 
policies to come into alignment by a technical standard- 
ization process. 

The issue of national interests in cryptography is a 
particular concern of companies that manufacture 
open-standards-based information technology products 
for a worldwide market. The market expects these prod- 
ucts to be secure. Yet, more and more consumers of 
these products are themselves multinational and look to 
the manufacturers to help them resolve the international 
cryptography issues inhibiting their worldwide informa- 
tion technology development. The persistence of unre- 
solved differences and export restrictions in national 
cryptography policies has an adverse impact on interna- 
tional market growth for secure open computing prod- 
ucts. Thus, it would be helpful to provide an 
international framework that provides global information 
technology products featuring common security ele- 
ments, while respecting the independent development 
of national cryptography policies. 

Nations have reasons for adopting policies that 
govern cryptography. Often these reasons have to do 
with law enforcement and national security issues. 
Within each country there can be debates between the 
government and the people as to the Tightness and 



acceptability of these policies. Rather than engage in 
these debates or try to forecast their outcome, it is more 
practical to accept the sovereign right of each nation to 
establish an independent policy governing cryptography 
5 in communication. 

Policies governing national cryptography not only 
express the will of the people and government, but also 
embrace certain technologies that facilitate cryptogra- 
phy. Technology choice is certainly one area where 

10 standardization can play a role. However, as indicated 
earlier this is not solely a technical problem, such that 
selection of common cryptographic technologies alone 
can not resolve the national policy differences. 

A four-part technology framework that supports 

15 international cryptography, which includes a national 
flag card, a cryptographic unit, a host system, and a net- 
work security server is disclosed by K. Klemba, R. Mer- 
cWing, International Cryptography Framework, in a 
copending U.S. patent application serial no 08/401 ,588. 

20 which was filed on 8 March 1995. Three of these four 
service elements have a fundamentally hierarchical 
relationship. The National Flag Card (NFC) is installed 
into the Cryptographic Unit (CU) which, in turn, is 
installed into a Host System (HS). Cryptographic func- 

25 tions on the Host System cannot be executed without a 
Cryptographic Unit, which itself requires the presence of 

. a valid National Flag Card before it's services are avail- 
able. The fourth service element, a Network Security 
Server (NSS), can provide a range of different security 
30 services including verification of the other three service 
elements. 

The framework supports the design, implementa- 
tion, and operational elements of any and all national 
policies, while unifying the design, development, and 

35 operation of independent national security policies. The 
framework thus gives standard form to the service ele- 
ments of national security policies, where such service 
elements include such things as hardware form factors, 
communication protocols, and on-line and off-line data 

40 definitions. 

Fig. 1 is a block diagram of the international cryp- 
tography framework 10, including a national flag card 
1 2, a cryptographic unit 1 4, a host system 1 6, and a net- 
work security server 18. Three of the four service ele- 

45 ments have a fundamentally hierarchical relationship. 
The National Flag Card (NFC) is installed into the Cryp- 
tographic Unit (CU) which, in turn, is installed into a 
Host System (HS). Cryptographic functions on the Host 
System cannot be executed without a Cryptographic 

so Unit, which itself requires the presence of a valid 
National Flag Card before it's services are available. 
The fourth service element, a Network Security Server 
(NSS), provides a range of different security services 
including verification of the other three service ele- 

55 ments. and thus acts as a trusted third party. 

Fig. 2 is a perspective view showing the four basic 
elements of the framework, including the cryptographic 
unit 1 4 and several national flag cards 1 2, a host system 
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16, and a national security server 18. In the following 
sections each service element is discussed in greater 
detail. 

NATIONAL FLAG CARD (NFC). In one embodi- 
ment, the NFC 12 is a small stamp sized (25 x 15 mm) 
ISO 7816-type smart card, i.e. a one chip computer 26 
having a non-volatile memory. The NFC is mounted on 
a rigid substrate and sealed in a tamper-proof package. 
The NFC is typically produced independently and dis- 
tributed by National agencies (e.g. United States Postal 
Service, German Bundespost). National agencies may 
also license NFC production and distribution to private 
industry. 

The action of the NFC service element is to enforce 
a Nation's policy governing the use of cryptography. An 
NFC is a complete computer that can be constructed as 
a multi-chip architecture to include custom integrated 
circuits. It also would include tamper resistance and 1 
unique identification features, making .unauthorized 
entry or duplication impossible. For example, the NFC ! 
could be sealed in such a way that opening its package 
would destroy any integrated circuit or data inside. The 
NFC could require receipt of an encrypted authorization 
issued by the National Security Server. All services of ? 
the NFC are provided via standard ISO 7816 message 
exchanged protocol between the N FC and other service 
elements. This format is identtal to the 
in Europe to support GSM in cellular voice services. ; j ». 

CRYPTOGRAPHIC UNIT ' (CU). ^ :The • CO is a Y 
tamper-resistant hardware component designed to pro-./ 
vide protected cryptographic services under the strict 
control of an NFC. CUs would be produced competi-v 
tively by system vendors and third parties and be free of /; 
import and export restrictions. Because the CU includes 
critical elements of security such as encryption algo- 
rithms and keys, it is likely that it would be certified {e.g. 
NIST, NCSC, or ITSEC Certified) for customer assur- 
ance. It is a feature of this embodiment of the invention 
that the CU does not contain any governing policy other 
than its dependence upon a NFC. This component is 
preferably designed for performance and protection with 
customization for a given Host System. ,:?;',•/ 

HOST SYSTEM (HS). The HS is identrf iabie as the 
hardware component that delivers secure information 
technology services directly to the user. HSs are typi- 
cally a general purpose information technology device 
and would be produced competitively in a .wide open , 
market. Examples include personal digital assistants, 
personal computers, workstations, laptops, palmtops," 
networked servers, main frames, network printers, or 
video display units. The function of the HS service ele- 
ment in the framework is to provide an Application Pro- 
gramming Interface (API) for accessing the CU service 
element. Preferably, CU support is provided as an 
option available on the HS. 

NETWORK SECURITY SERVER (NSS). The NSS 
is a network node designed and designated to provide 
trusted third party security services. For example, any 
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network access, such as via modems 30, 32 over a net- 
work 34, must be authenticated by the NSS. In the con- 
text of national security, NSSs are preferably developed, 
owned, and operated by government agencies. Some of 
the functions provided by the NSS service element 
include service element authentication, message stamp 
authentication, national policy enforcement, and crypto- 
graphic key distribution. The importance of the NSS can 
rise sharply in environments where a strong degree of 
verification is prerequisite to cryptographic use. The 
NSS also plays a significant role in the interoperability of 
differing National cryptographic policies. 

SCOPE OF THE FRAMEWORK. The scope of the 
framework is largely defined by the scope of the NFCs. 
The basic scope of the NFCs is that of a domain. A 
domain can be as large as worldwide and as small as a 
business unit. At the domain level there is no unique dis- 
tinction among its members. While this framework pri- 
marily focuses on National and International domains 
(e.g. France, Germany, United States! United Kingdom, 
European Commission, NATO, North America, G7) 
other domains or sub-domains are also considered. For 
example, industry domains (e.g. Telecom, Healthcare, 
Financial Services, Travel), corporate domains (e.g. 
Hewlett-Packard, Ford Motor Company, CitiBank), 
association domains (e.g. IEEE, ISO, X/Open), service . 
domains, (e.g. , to anc U 
product ■ domains {e.g. Lotus, Microsoft. General ^ 
Motors, /Proctdr& Gamble). 'V 

Beyond domains and subdomains the scope of the . 
framework can optionally be expanded to define unique- 
ness within a domain. Again it is the NFCs that make 
this narrower scope ' possible,. Providing uniqueness. • 
means allowing for the transfer of unique or personal 
data to be transferred to the NFC either at the time of 
purchase or at the point of initial validation. NFCs are 
considered anonymous when dealing at the domain 
level. When uniqueness is added, NFCs are no longer 
anonymous. 

INTERCONNECT OF FRAMEWORK ELEMENTS. 
The interconnection of service elements (e.g. NFC, CU, 
HS, NSS) of this framework is accomplished by the 
adoption of standard Application Programming inter- 
faces (e.g. X/Open, OSF) and industry standard proto- 
col exchanges (e.g. TCP/IP, ISO, DCE, X.509). The 
interconnection of elements may be synchronous (i.e. 
on-line), asynchronous (i.e. off-line), local (e.g. runtime . 
library), remote (e.g. RPC) or any combination of these. 
For example, a policy that involves personalization of 
NFCs could perform a one time authorization function 
via a NSS making it unnecessary for future on-line veri- 
fication with an NSS until the NFC expires. 

Beyond the physical interconnection of the frame- 
work's service elements lies the message exchange 
between the elements and the actual services provided 
and requested via this message exchange. Fig. 3 illus- 
trates the message exchange paths, between an NFC 
12 and a CU 14 (path 35), between the CU 14 and an 
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HS 16 (path 36). and between the HS 16 and an NSS 
1 8 (path 37). A virtual connection 38 exists between the 
NFC and the NSS. Messaging protocol between the HS 
and the CU along the path 36 are best taken from cryp- 
tographic API standardization efforts (e.g. NSAs Cryp- 
tographic API, Microsoft's Cryptographic API). The 
messaging protocol between the CU and the NFC along 
the path 35 is categorized into two groups: initialization 
protocols, and operational protocols. The initialization 
protocols must be successful before operational proto- 
cols are active. 

Critical to the implementation of the framework is 
the provision of a fundamental technology that allows 
the production of the various service elements. While 
various implementations of the service elements are 
within the skill of those versed in the relevant art, there 
exists a need for specific improvements to the state of 
the art if the full potential of the framework is to be real- 
ized. 

Consequently, it would be useful to provide a com- 
mon, accepted cryptography framework, wherein inde- 
pendent technology and policy choices can be made in 
a way that still enables international cryptographic com- 
munications consistent with these policies. Further, it 
would be useful to provide various configurations that 
allow flexibility in the implementation of such a cryptog- 
raphy framework without compromising the security and 
control afforded by such framework, in particular where 
the policy enforced within the framework was available 
in any one of several different configurations. 

SUMMARY OF THE INVENTION 

The invention provides a flexible policy element that 
may be variously configured for chosen applications 
that employ a four-part technology framework which 
supports international cryptography. The cryptography 
framework includes the policy, i.e. a national flag card, 
a cryptographic unit, a host system, and a network 
security server. Three of the four service elements have 
a fundamentally hierarchical relationship. The National 
Flag Card (NFC), also referred to herein a the "policy," 
is installed into the Cryptographic Unit (CU) which, in 
turn, is installed into a Host System (HS). Cryptographic 
functions on the Host System cannot be executed with- 
out a Cryptographic Unit, which itself requires the pres- 
ence of a valid National Flag Card before it's services 
are available. The fourth service element, a Network 
Security Server (NSS), can provide a range of different 
security services including verification of the other three 
service elements. 

The invention specifies several different configura- 
tions that support policy within a cryptographic system, 
such as the international cryptography framework. Such 
configurations provide considerable flexibility that allows 
the framework to be adapted to various connection 
schemes involving, at least, the cryptographic unit and 
the policy. In all embodiments of the invention, a control- 



ling principle is that cryptography is not made available 
, to a user of the cryptographic unit in the absence of a 
policy. 

"Die invention also provides various improvements 
5 in interoperability and allows the coexistence of different 
configurations. In the exemplary embodiment of the 
invention, such configurations include dedicated appli- 
cations, e.g. a policy provided in a cryptographic unit 
having either a built-in or local smart card reader, or a 
10 policy in a remote smart card reader; and shared appli- 
cations, e.g. a policy provided in a host system local 
smart card reader. 

BRIEF DESCRIPTION OF THE DRAWINGS 

15 

Fig. 1 is a block diagram of an international cryptog- 
raphy framework, including a national flag card, a 
cryptographic unit, a host system, and a network 
security server; 

20 

Fig. 2 is a perspective view showing the four basic 
elements of the framework, including a crypto- 
graphic unit and several national flag cards, a host 
system, and a national security server; 

25 

Fig. 3 illustrates the message exchange paths, 
between an NFC and a CU, between a CU and an 
HS, and between an HS and an NSS; and 

30 Fig. 4a is a schematic diagram that represents 
physical and logical connection end points of the 
four framework service elements in an untrusted 
environment; 

35 Fig. 4b is a schematic diagram that represents 
physical and logical connection end points of the 
four framework service elements in a trusted envi- 
ronment; 

40 Figs. 5a-5f are block schematic diagrams that rep- 
resent the n-ary relationships between the frame- 
work elements through connection end points that 
are established between a policy and a crypto- 
graphic unit; and 

45 

Figs. 6a-6f are block schematic diagrams that rep- 
resent the n-ary relationships between the frame- 
work elements through connection end points that 
are established between a policy and an NSS; 

50 

Figs. 7a-7c provide a block schematic diagram of a 
dedicated policy element according to three alter- 
native arrangements of a first preferred embodi- 
ment of the invention; 

55 

Fig. 8 is a block schematic diagram of another ded- 
icated policy element according to a second pre- 
ferred embodiment of the invention; 
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Fig. 9 is a block schematic diagram of a shared pol- 
icy element according to a third preferred embodi- 
ment of the invention; and 

Fig. 10 is a block schematic diagram of yet another 
dedicated policy element according to a fourth pre- 
ferred embodiment of the invention. 

DETAILED DESCRIPTION OF THE INVENTION 

National cryptography policy often varies by indus- 
try segment, political climate, and/or message function, 
This makes it difficult to assign one uniform policy 
across all industries for all time, consequently, the flexi- 
bility of a cryptography framework that incorporates a 
national flag card is very attractive. The preferred 
embodiment of the invention is therefore directed to 
resolving problems surrounding international cryptogra- 
phy within a framework that may be used to support the 
design and development of any national policy regard- 
ing cryptography. 

The invention provides a variety of policy configura- 
tions for an international cryptography framework that 
has four service elements, where each service element 
offers different types of services. The invention is dis- 
cussed in connection with the cryptography framework, 
which is presently the preferred embodiment of the 
invention. It should be appreciated that the invention 
has application within other systems and is therefore 
not limited to the framework described herein, nor is it 
limited to applications that support cryptography, but 
may be used with any application that requires a dedi- 
cated, tamper-proof policy element. 

Although a primary objective of a system, such as 
the international cryptography framework, is to maintain 
contact with the policy to enforce a government dictated 
discipline, there are a variety of ways and different con- 
figurations that could be used to accomplish such objec- 
tive. All of these configurations can preserve the 
essence of international cryptography framework, i.e. 
the cryptographic function is not allowed to operate in 
the absence of a policy. The basic assumption in each 
of the different configurations descried hereinbelow is 
that the cryptographic unit cannot provide the host sys- 
tem with any cryptographic functions without being in 
contact with the policy. For purposes of this discussion, 
the term In oontact with" is not limited to mean that the 
policy card is physically present at that location, but the 
essence of the invention is that there is a policy some- 
where that controls the cryptographic unit, e.g. the pol- 
icy could be located millimeters from the cryptographic 
unit or it could be located miles away from the crypto- 
graphic unit. 

Thus, policy execution, storage, and control func- 
tions may be divided between the NFC and the crypto- 
graphic unit. For example, the policy can be a software 
based policy control function that is processed in a 
trusted environment, such as a trusted kernel. Further, 



the framework elements that are concerned with trust. 
e.g. the NFC, cryptographic unit, and NSS, can have 
either a physical or logical connection. Additionally, the 
cryptographic unit can be a software based crypto- 
5 graphic engine having an execution policy that is con- 
trolled in a trusted environment, such as a trusted 
kernel. 

The policy itself has no access to other data, such 
as user data that is processed in the cryptographic unit. 

10 Thus, the policy does not admit information that could 
compromise it's integrity. Accordingly, the cryptographic 
unit as controlled by a given policy, remains determinis- 
tic for all configurations. 

Another requirement of the system is that the policy 

is must know which cryptographic unit it is controlling, 
although cryptographic unit does not have to know by 
which policy it is controlled. Thus, the policy only con- 
trols a deterministic number, i.e. a main specific or iden- 
tified, of cryptographic units. It is possible for these to be 

20 updated by an NSS. 

Additionally, the either the cryptographic unit or pol- 
icy can request services of the NSS, which in turn ena- 
bles further distribution or delegation of the policy 
function to a on-line network security server instead of a 

25 physical token card. In this embodiment of the invention, 
the card itself is present at the network security server 
and can therefore activate one or more cryptographic 
units in near real time. For example, a new crypto- 
graphic unit is installed within a system. The new unit 

30 accesses the NSS for activation. Because policy is 
installed, the system is allowed to continue the use of 
cryptography. In this example, one of the functions of 
the policy is to allow the addition of the new unit The 
policy activates the unit through the NSS, which in turn 

35 sends activation to the unit. Thus, if the name of the new 
user or unit is in policy, then the policy allows activation 
of the user/unit This aspect of the invention allows the 
system to be very dynamic, yet preserves physical con- 
trol of the system, such that the enabled application (in 

40 this example cryptography) is tost if the policy is 
removed from the NSS. This embodiment of the inven- 
tion preserves the physical characteristic of the policy 
within the framework, even though the policy is applied 
within a very dynamic environment. Accordingly, the 

45 policy controls the operation of each specific crypto- 
graphic unit. 

The following discussion concerns the service ele- 
ments end points and communication characteristics. 
Fig. 4a is a schematic diagram that represents 

so physical and logical connection end points of the four 
framework service elements in an untrusted environ- 
ment; Fig. 4b is a schematic diagram that represents 
physical and logical connection end points of the four 
framework service elements in a trusted environment. 

55 In particular, Fig. 4b represents the trusted 
processing capability which supports both, the trusted 
communication channel and the information privacy 
protection. Generalization and Relationship Models. To 
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be able to generalize the case of form-factors and to 
focus mainly on the variability of the connections and 
interactions between the essential elements. NFC. 
cryptographic unit, HS and NSS, the figures have been 
in the following manner. Physically connected end- 
points, referring to physical links, are represented by 
plain lines and broken lines represent logical links. 

The two service elements, the cryptographic unit 1 4 
and the policy 12 are each connected via an end-point 
represented by physical means which consist of three 
basic components: the policy support - which stores 
and protects securely the policy itself, the policy reader 
R - which extracts the policy from the support, and a 
communication link which maintains a viable communi- 
cation between the reader and the peer receiver in the 
host system. 

The transmitter and the receiver have a compatible 
communication system or they are connected to a gate- 
way whose function is to convert heterogeneous com- 
munication standards. The later communication 
connection can be extended to a mashed network of 
various communication standards. Each end point of 
the communication link is compatible with, on one side, 
the policy reader R and on the other side, the peer 
receiver. 

A transition from trusted physical components to 
trusted execution of logical components. Figs. 5a-5f are 
block schematic diagrams that represent the n-ary rela- 
tionships between the framework elements through 
connection end points that are established between a 
policy and a cryptographic unit. Three examples can be 
given to illustrate the flexibility of the architecture when 
dealing with diverse physical elements. 

Example 1 : A 1 to 1 case. A policy support is a con- 
tact/contactless smart card, the policy reader R is 
the contact/contactless reader which transmits the 
information over an RS232 line to a cryptographic 
unit, represented by an internal bus board with a 
chip. One instance of this case is represented by a 
PCI board with a plug-in chip. The communication 
with the NFC is made through an input/output con- 
troller for an RS232 connection located on a distant 
system. 

Example 2: An N to 1 case. A policy support is a 
contact smart card, the policy readers Rs are the 
contact readers tethered to a board that allow an N 
to 1 relationship. An instance of a representation is 
the same PCI board with 8 tethered readers. 

Example 3: A cascade case. The policy support is a 
contact smart card, the policy readers Rs are the 
contact readers tethered to a cryptographic unit 
which further delegates the policy controls to the P 
end user cryptographic units. With the telecommu- 
nication example of a GSM infrastructure, i.e. a 
Global System for Mobile communication system , 



the AUC - Authentication Centre represents the 
intermediate P CUs and the GSM phones are the M 
end-users. The telecommunication infrastructure 
provides the means to the end-points connections 
- 5 for the NFCs and the cryptographic units. 

NFC to NSS communication. Before starting the 
discussion between the NFC and the cryptographic unit, 
it is important to consider the trusted policy control sys- 
10 tern of the NSS as an application of the previous cases 
NFC to cryptographic unit 

Two major categories of interactions are identified 
between the NFC and the NSS: 

is • The first category encompasses all attributes 
related to the renewal of uses for an already used 
algorithm, key management scheme, or constraint 
data. Further updates of keying material, the secret 
data, and the timing values are also part of that cat- 

20 egory. Installation of new policies, replacement, and 
obsolescence of existing policies are the last plank 
within that category. 

• The second category includes the abnormal behav- 
25 iors of the cryptographic unit, detection of active 
attacks, or replacement of trusted components. 

Both categories of relations are based on a built-in 
interaction policy between the NFC and the NSS. Both 

30 categories of interactions can be expressed in the rela- 
tionship model as represented in Figs. 6a-6f, which are 
block schematic diagrams that represent the n-ary rela- 
tionships between the framework elements through 
connection end points that are established between a 

35 policy and an NSS. 

A particular case is the cascade. The cascade rep- 
resents a typical delegation structure similar to a certifi- 
cation hierarchy within a network of trusted third parties 
(TTP). An example of this structure is a mashed net- 

40 work of TTPs in Europe, between the UK, France, and 
Germany, implementing a common key recovery 
scheme based on national TTP representations. 

Logical components. Another potential representa- 
tion of the policy support can include a trusted proces- 

45 sor controlled software residing in a host CPU. 

The communication mechanisms are the existing 
interprocess communication systems and the communi- 
cation vehicle are the envelopes. 

Trusted Versus Untrusted Processing Environment. 

so By construction, the implicit interaction policy is built in 
the trusted service elements. Therefore, any service 
element, the cryptographic unit, the NFC, the Host, or 
the NSS, relies on a trusted execution capability to set 
up the communication channel. Moreover, the originator 

55 must also trust the recipient to uphold the secret infor- 
mation - touchpoint data - once the information is deliv- 
ered to the recipient. 

Figs. 7a-7c provide a block schematic diagram of a 
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dedicated policy element according to three alternative 
arrangements of a first preferred embodiment of the 
invention. 

In Fig. 7a, the policy 12 is connected to the crypto- 
graphic unit 1 4 by a built-in smart card reader 40, where s 
the smart card reader is solely dedicated to the function 
of connecting the policy to the cryptographic unit. The 
cryptographic unit is then connected to the host system . 
1 6. For example where the cryptographic unit is a circuit 
card, the circuit card is plugged into a slot on the host 10 
system motherboard (see Fig. 7b). The scanner itself 
may be any well known scanning device that is able to 
read a smart card. 

In the example of Fig. 7b, where the cryptographic 
unit 14 is mounted on a circuit card 44, the crypto- is 
graphic unit comprises a tamper resistant pad and con- ■ 
tainer mounted on the circuit card, thus providing 
additional tamp©' resistance. The circuit card is con- . 
nected to the host system motherboard 46 a slot 45. [ 
Traces 42 on the circuit card lead to a drawer at the back ; W 
of the host system 16, 7.e. the computer, that serves to 
receive the policy 12 within a hard wired receptacle or 
other port, such as the smart card reader 40. 

In the example of Fig. 7c. the cryptographic unit 14 
is mounted directly on the motherboard 46 and the pot- % 25 
icy 12 is connected to the cryptographic unit, for exam- v . ; 
; pie via a receptacle^ in [trie cryptographic ^ unit or in the ' 
; motherboard itself. **.; \ ; ; '•; i \- V s ; ,'■ '■ 

In all three - examples above, a smart card reader . * 
may be used to connect the policy to the cryptographic 30 
unit, where the smart card reader is both dedicated to 
reading only the policy, and where it is built into, or irrti- . - 
mately associated with, the cryptographic unit.;; : y- . ' " 

Fig. 8 is a block schematic diagram of another ded- 
icated policy element according to a second preferred 35 
embodiment of the invention. In this embodiment of the 
invention, the cryptographic unit 14 is mounted on a cir- 
cuit card 44, and the circuit card is connected to the host 
system motherboard 46 via a motherboard slot 45. The 
cryptographic unit is connected to a connector 52 on the . • ' ao 
circuit card by various leads or traces 42. Inoneembod- ;' 
t -. iment of the invention, the connector provides a stand- 0 
ard RS-232 port, such that the circuit :card includes a ; ' 1 
serial port. 

A separate, dedicated smart card reader 40 has a 45 
connector 54 that allows a cable 50 to connect the 
. smart card reader to the circuit card at the circuit card , 
connector 52. The policy 12 is read by the smart card 
4 reader 40. Thus, in this embodiment of the invention, 
the smart card reader is dedicated and local to the host, so 
but is located away from the cryptographic unit, i.e. it is 
not built into the cryptographic unit. 

Fig. 9 is a block schematic diagram of a shared pol- 
icy element according to a third preferred embodiment 
of the invention. In this embodiment of the invention, the ss 
cryptographic unit 14 is mounted on a circuit card 44, 
and the circuit card is connected to the host system 
motherboard 46 via a motherboard slot 45. The crypto- 



graphic unit is connected to a connector 52 on the cir- 
cuit card by various leads or traces 42. In one 
embodiment of the invention, the connector provides a 
standard RS-232 port, such that the circuit card has a 
serial port. 

A separate, shared smart card reader 40 has a con- 
nector 54 that allows a cable 50 to connect the smart 
card reader to the circuit card at the circuit card connec- 
tor 52. The policy 12 is read by the smart card reader 
40, as with the embodiment of the invention shown in 
Fig. 8 above. 

However, it is both expensive and inefficient to pro- 
vide a smart card reader whose only function is to hold 
the policy. In this embodiment of the invention, the smart 
card reader can be used to read other smart cards 60, 
62, 64 to use other functions 66, 68 that may or may not 
be provided on the circuit card 44 or motherboard 46. 
This configuration is referred to as shared because the 
smart card reader is shared with a policy and, for exam- 
ple an ID card, whereas in the previously discussed ' 
embodiments of the invention the smart card reader 
was dedicated to performing only a policy reading func- 
tion. 

In one form of this embodiment, the functionality of 
the policy 1 2 is put into a smart card 72 along with an ID 

, card function 70, such that in. one smart card there is, 
.^hctionalitY !fplr both ^an ID and a policy This embodiv 

. ment of the invention is useful for such applications as a 
passport or visa that would include both citizenship cre- 
dentials and authorization for the use of cryptography. 
Thus, trie smart card not only informs an agency or sys- 
tem of the user's identity, but also activates cryptogra- 
phy in accordance with government policy. ; .} 
;*ln use, this shared configuration activates the cryp- . 
tographic function and includes with it some other func- 
tions, such as ID, that may also include ceratin 
privileges. The shared configuration lets the system 
know the user's identity and thereby enables such privi- 
leges, enforces security, and creates an audit trail of use 
of the system, in addition to activating the cryptographic 
function. 7 . . \ ' ' ■ ->..'.■ 
' There is, in the security industry, a difference 

{ between rights and capabilities;: This embodiment of the 
invention provides a smart card that provides a user 
with both rights to use cryptography and activates the 
cryptography with certain capabilities. Thus, a shared 
smart card configuration provides both right and capa- 
bility on an individual basis. 

Because the smart card reader is shared, separate 
smart cards may be used for different individuals and 
different functions. For example, a policy may be read 
by the smart card reader, where the policy may be one 
of multiple functions on a smart card, such that the 
bearer of the card receives rights to use cryptography, 
as well as other rights/privileges. Other users of the sys- 
tem may have a smart card that does not have a policy. 
For such individuals, cryptography does not exist in the 
system, although these individuals may have certain 
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other rights and/or capabilities. In both cases, an ID 
function associated with the smart card may be pro- 
vided that serves to control access to the system, while 
maintaining an audit trail of system use. 

Thus, in this embodiment of the invention, the smart s 
card reader is used for multiple purposes, i.e. it is 
shared between the policy and other functions, and is 
local to the host, but is located away from the crypto- 
graphic unit, re. rt is not built into the cryptographic unit. 

Fig. 1 0 is a block schematic diagram of yet another w 
dedicated policy element according to a fourth preferred 
embodiment of the invention. In this embodiment of the 
invention, the host is connected via a network 70, 71 , 72 
to another host that has any one of the above described 
combinations of cryptographic unit 14 and policy 12. 15 
The remote cryptographic unit 84 is activated from the 
policy 12 across the network. The remote cryptographic 
unit may be otherwise configured as above, e.g. 
mounted on a circuit card 74 that is connected to a 
motherboard 76 via a card slot 75 on the motherboard. 20 

In one form of this embodiment of the invention, the 
policy controls a small number of cryptographic units 
through the network. The number of cryptographic units 
that the policy is managing via the network is limited by 
the capability of the policy's bandwidth in processing 25 
power. To address this limitation of the policy, another 
form of this embodiment of the invention provides an 
enabling functionality at a first cryptographic unit 1 4 that 
is transferred from the policy to the cryptographic unit 
14. The cryptographic unit, in turn, enables all other 30 
cryptographic units in the system. If the policy is 
removed, the prime cryptographic unit loses its function 
and, with it, all of the other cryptographic units lose their 
function. Thus ( a more powerful cryptographic unit is 
empowered to activate other cryptographic units, all in 35 
accordance with and under the control of a policy, 
where the policy instructs the prime cryptographic unit 
with regard to which other units may be enabled, who 
may use these units, and what rights/capabilities attach 
to such users. 40 

Although the invention is described herein with ref- 
erence to the preferred embodiment, one skilled in the 
art will readily appreciate that other applications may be 
substituted for those set forth herein without departing 
from the spirit and scope of the present invention. 45 
Accordingly, the invention should only be limited by the 
Claims included below. 

Claims 

50 

1. A cryptographic framework for providing uniform 
encryption that operates consistently and in con- 
formance with diverse national, regional, industry, 
or agency cryptography policies, comprising: 

55 

a policy (12) adapted to accommodate any 
cryptography scheme required by a particular 
national, regional, industry, or agency cryptog- 



raphy policy of the domain in which said frame- 
work is used; 

a cryptographic unit (14) including a cryptogra- 
phy engine, said cryptographic unit adapted to 
implement said cryptography scheme, wherein 
said policy is connected to said cryptographic 
unit, such that cryptographic functions cannot 
be executed in the absence of said policy; and 
at least one reader (R) for connecting said pol- 
icy to said cryptographic unit. 

2. A cryptography framework, comprising: 

a policy (12) adapted to accommodate any 
cryptography scheme required by a particular 
application, wherein said policy implements a 
selected cryptography standard; 
a cryptographic unit (14) including a cryptogra- 
phy engine, said cryptographic unit adapted to 
implement said cryptography scheme if and 
only if said cryptographic is used in combina- 
tion with a valid policy; and 
a host system (16) adapted to implement an 
information technology application, said host 
system arranged for communication with said 
cryptographic unit and adapted to implement 
said cryptography scheme if and only if said 
host system is used with combination with a 
cryptographic unit and a valid policy; and 
a reader (R) for connecting' said policy to said 
cryptographic unit. 

3. A policy for controlling operation of a cryptographic 
unit, comprising: 

a policy card (12); and 

at least one reader (R) for connecting said pol- 
icy card to said cryptographic unit, wherein said 
policy is connected said cryptographic unit, 
such that cryptographic functions cannot be 
executed in the absence of said policy. 

4. The framework of either of Claims 1 and 2, wherein 
said reader (R) is a shared reader. 

5. The framework of either of Claims 1 and 2. wherein 
said reader (R) is built into said cryptographic unit. 

6. The framework of either of Claims 1 and 2, wherein 
said reader (R) is local to said cryptographic unit. 

7. The framework of either of Claims 1 and 2, wherein 
said reader (R) is remote from said cryptographic 
unit 

8. The framework of either of Claims 1 and 2, wherein 
said reader (R) is a dedicated reader. 
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9. The framework of either of Claims 1 and 2, wherein 
said cryptographic unit (14) is adapted to receive 
and secure said policy therein. 

1 0. The framework of any of Claims 1 to 9, wherein said s 
cryptographic unit (14) implements a generic cryp- 
tography engine; and wherein said policy is 
adapted to assure that said generic cryptography 
engine and the use thereof comply with national, 
regional, industry, or agency cryptography policy of 10 
the domain in which said framework is used. 

11. The framework of any of Claims 1 to 10, wherein 
said policy (12) is adapted to selectively implement 

at least one additional cryptography standard in is 
combination with said cryptographic unit. 

12. The framework of Claim 11, wherein said selected 
cryptography standard may comprise any of a 
selected cryptography algorithm, a selected level of 20 
cryptography, a national policy, information person- 
alization, system and network access metering, 
and renewable cryptography. 

13. The framework of Claim 1 1 , said at least one other 25 
standard including any of establishing identity, 
establishing privileges, establishing rights, enabling 
capabilities, enforcing security, and creating an 
audit trail. 

30 

14. The framework of either of Claims 1 and 2, wherein 
said policy (1 2) is a tamper-resistant smart card. 

15. The framework of any of Claims 1 to 14, wherein 
said policy (1 2) controls the operation of more than 35 
one cryptographic unit. 

16. The framework of any of Claims 1 to 15. wherein 
said policy (12) controls the operation of a prime 
cryptographic unit which, in turn, activates and con- ao 
trols the operation or one or more other crypto- 
graphic units. 
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(54) Method and apparatus for enforcing the use of cryptography in an international 
cryptography framework 

(57) A cryptographic framework consists of four 
basic service elements that include a national flag card, 
a cryptographic unit, a host system, and a network 

^securityserverrThree of the four service elements have 
a fundamentally hierarchical relationship. The National 

-Flag Card (NFC) is installed into the Cryptographic Unit 
(CU) which, in turn, is installed into a Host System (HS). 

* Cryptographic functions on the Host System cannot be 
executed without a Cryptographic Unit, which itself 
requires the presence of a valid National Rag Card 
before it's services are available. The fourth service ele- 
ment, a Network Security Server (NSS), can provide a 
range oT different security services including verification 
oHhe o&er three service elements. Several different 
conf iggrajions that support policy within a cryptographic 
systerruallbw tne framework to "Be adapted to various 
connection schemes involving, at least, the crypto- 
graphic unit and the policy, including dedicated applica- 
tions, e.g. a policy provided in a cryptographic unit 
having either a built-in or local smart card reader, or a 
policy in a remote smart card reader; and shared appli- 
cations, e.g. a policy provided in a host system local 
smart card reader. 
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